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1.0  INTRODUCTION 


The  establishment  of  a  Software  Engineering  Institute  (SEI) 
is  proposed  as  a  part  of  the  DoD  Software  Technology  for 
Adaptable  and  Reliable  Systems  (STARS)  Program.  This  Plan 
describes  the  concept  and  mission  of  the  SEI  and  discusses 
proposed  operational  characteristics  and  organizational  and 
management  alternatives.  The  document  represents  an  extension 
of  the  work  initiated  by  the  STARS  workshop,  February  7-9,  1983. 

The  STARS  Program  has  been  established  to  advance  the 
state-of-the-art  and  practice  in  software  engineering  of  DoD 
embedded  computer  systems  (ECS).  This  program  will  make  a 
significant  impact  on  the  rate  of  research  in  software  tech¬ 
nology  —  software  engineering  techniques  and  tools.  However, 
this  impact  will  not  have  a  corresponding  effect  on  the  state- 
of-practice  in  the  DoD  and  the  defense  industry  unless  the 
technology  can  make  the  transition  to  application  use.  The 
SEI  is  to  provide  a  vehicle  for  the  effective  transition  of 

new  software  engineering  techniques  and  tools. 

^ V  v>.) v \ At  \  _  \ 

■‘"The  purpose  of  thff(sEIj  is  to  bring  to  the  DoD  Services  and 
Agencies  the  best  available  tools  and  techniques  for  the  efficient 
design  and  production  of  reliable  and  adaptable  software.  It  will 
maintain  a  state-of-the-art  software  development  environment  and 
take  the  lead  in  developing  Systems  Interface  Standards  to 
maintain  compatibility  among  standard  environment  adopted 
by  the  Services.  The  SEI  will  evaluate  new  techniques,  integrate^ 


promising  tools  into  the  environment,  demonstrate  their  effective¬ 
ness  for  DoD  projects,  and  provide  training,  documentation  and 
user  assistance., 

,  This  document  describes  the  characteristics  and  operations 
of  the  Software  Engineering  Institute  along  with  the  issues  and 
alternatives  surrounding  its  establishment.  The  document  reflects 
the  comments  provided  by  attendees  of  the^sVARS  workshop  held 
February  7-9,  1983.  The  foundation  for  the  document  is  prepared 
in  section  2  in  which  the  problems  of  technology  transition 
are  discussed.  Particular  emphasis  is  placed  on  software  engineering 
environments  and  their  role  in  technology  transition.  Section  3 
presents  the  mission,  objectives  and  functions  of  the  Insititute. 

A  discussion  of  what  the  Insititute  will  do  is  complemented  by 
a  brief  description  of  how  it  might  operate  and  the  types  of 
personnel  required. 

The  Institute  support  base,  management,  hosting,  and  relation 
to  STARS  were  key  areas  of  discussion  at  the  STARS  workshop. 

There  are  many  alternatives  to  consider.  Section  4  outlines  the 
issues,  the  alternatives  and  recommended  approach  in  each  of 
these  areas.  Section  5  presents  an  implementation  plan  that 
is  sufficiently  generic  to  apply  to  most  alternatives  discussed 
in  Section  4. 


2 . 0  BACKGROUND 


This  section  briefly  discusses  technology  insertion  in 
general  and  specifically  for  software  technology.  Software 
development  and  support  environments  are  characterized  and 
contrasted.  The  characteristics  of  defense  embedded  computer 
systems  are  described.  Finally,  the  Ada  Programming  support 
Environment  is  noted  and  initial  assumptions  are  stated. 

2.1  TECHNOLOGY  INSERTION 

To  be  effective,  technology  advancements  must  be  integrated 
with  the  technology  state  in  active  use.  Unless  a  totally  new 
paradigm  for  software  production  and  in-service  support  is  being 
introduced,  new  tools  and  technology  must  be  engineered  so  that 
they  can  function  in  existing  environments  and  can  be  used  har¬ 
moniously  in  conjunction  with  existing  techniques  and  practices. 
This  involves  the  solution  of  interface  and  data  representation 
problems.  It  also  involves  the  investigation  of  usage  modes 
which  allow  mutually  supportive  use  of  the  new  and  existing 
techniques  and  practices. 

To  have  effect  on  the  state-of-the-pract ice ,  technology 
advancements  must  be  delivered  to  practitioners.  The  technology 
must  be  packaged  in  a  conveniently  usable  form,  transferred 
to  practitioners'  organizations,  and  supported  after  being 
transferred.  Also,  practitioners  must  be  taught  how  to  use 
the  new  technology.  Thus,  delivery  involves  the  solution  of 


many  problems  concerning  usability,  human  engineering,  utility 
demonstration,  education,  maintenance,  and  enhancement. 

Considerable  resources  are  required  to  package,  integrate, 
and  deliver  new  software  engineering  tools  and  techniques.  The 
process  involves  evaluating  technology,  packaging  it  with 
proper  human  engineering  characteristics  and  documentation, 
integrating  it  with  other  accepted  techniques  and  tools,  providing 
proper  training,  and  providing  life  cycle  support.  As  noted 
in  the  following  section,  neit  .er  the  research  organizations 
nor  the  development  and  support  organizations  have  budgeted 
for  these  activities.  Without  budgets  specifically  earmarked 
for  this  purpose,  transition  of  technology  will  continue  to  be 
slower  than  considered  desireable.  There  is  a  natural  resistance 
by  development  and  support  personnel  to  new  methods  of  software 
development  and  support.  This  resistance  is  also  a  factor  in 
slowing  the  transition  of  software  engineering  technology. 

The  combined  result  of  these  circumstances  causes 
significant  gap  between  the  state-of-the-art  and  the 
state-off-the-pract ice  in  software  engineering.  To  get  the 
maximum  benefit  from  the  STARS  Program  and  other  software 
engineering  research,  this  gap  must  be  narrowed.  Conventional 
approaches  to  this  problem  have  not  been  effective  enough.  A 
Software  Engineering  Institute  will  provide  the  proper  focus 
to  make  a  positive  impact  on  this  problem. 


2.2  SOFTWARE  TECHNOLOGY-RESEARCH,  DEVELOPMENT  AND  APPLICATION 

The  effective  integration  and  delivery  of  software  engi¬ 
neering  technology  is  not  occurring  fast  enough  in  defense 
systems  today.  Although  much  useful  research  is  conducted, 
too  little  technology  packaging  and  transfer  to  operational 
use  is  accomplished.  There  are  reasons  for  this  slow  transfer 
of  technology. 

Technology  research  usually  is  performed  by  organizations 
different  from  those  that  develop  and  support  application  software. 
The  mission  of  these  research  organizations  is  to  develop  innovative 
techniques  and  tools  for  software  engineering.  This  mission 
does  not  include  packaging,  integration,  and  delivery  of  this 
technology.  The  organizations  that  develop  and  support  applica¬ 
tion  software  are  totally  absorbed  in  meeting  schedules  and 
operational  objectives.  They  are  motivated  to  avoid  risk  and 
have  little  incentive  to  bring  new  software  engineering  tech¬ 
nology  into  their  operation.  Therefore,  there  is  a  gulf 
between  the  R&D  organizations  and  the  software  development  and 
support  organizations  that  stifles  the  transfer  of  technology. 

2.3  SOFTWARE  DEVELOPMENT  ENVIRONMENTS 

Because  the  current  state-of-the-practice  of  software 
engineering  is  characterized  by  diverse  and  incompatible 
techniques  and  tools,  the  introduction  of  new  techniques  and 
tools  usually  causes  considerable  disruption.  This  disruption 
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is  caused  by  required  reorientation  of  processes  and  conversion 
activities,  e.g.,  conversion  of  code  from  assembly  language 
to  a  structured  high  order  language  (HOL)  to  take  advantage  of 
the  HOL  and  structured  programming  techniques. 

The  software  scene  is  one  of  thousands  of  unique  development 
teams,  each  with  its  own  particular  set  of  tools  and  practices  - 
its  own  environment.  Commonality  of  tools  and  practices  is  found 
on  a  small  scale,  here  and  there,  A  multitude  of  development 
environments  are  used  by  DoD's  software  developers;  different 
host  computers,  different  operating  systems,  different  tools, 
utilities,  editors  and  so  on.  There  are  subtle  differences 
between  different  versions  of  languages,  between  different 
hosts,  between  different  compilers,  between  different  code 
generators. 

In  the  long  run,  it  is  inefficient  for  DoD  to  apply 
multitudes  of  inconsistent  development  environments.  Economy 
of  scale  is  non-existent.  The  DoD  pays,  directly  or  indirectly, 
for  upgrades  of  all  of  these  environments  as  each  developer 
discovers  new  and  better  tools  and  uniquely  applies  them  to 
his  own  environment.  Given  the  current  state  in  which  substan¬ 
tial  development  and  experimentation  is  needed,  coordinated 
development  of  different  approaches  is  appropriate,  but  there 
must  be  a  clear  path  toward  development  of  commonality  and 
standard  interfaces. 


1.4  IN-SERVICE  SUPPORT  ENVIRONMENTS 


When  the  software  product  enters  the  operational  and  service 
support  phase,  the  product  is  supported  by  one  of  a  few  central 
groups.  The  diversity  of  development  environments  is  in  contrast 
to  the  few  centralized  software  product  support  centers.  However, 
these  few  centers  mu3t  obtain  and  maintain  unique  environments  for 
each  supported  system.  The  reasons  for  this  are  several,  but 
one  stands  out:  Each  operational  software  product  that  results 
from  a  given  environment  is  most  safely  supported  (modified  or 
fixed)  if  the  needed  work  is  accomplished  on  the  same  environment 
on  which  it  was  developed.  Thus  the  many  development  environments 
must  be  maintained  by  the  support  centers.  Even  though  the 
essential  differences  are  at  the  level  of  methodology  with  a 
conceptually  similar  but  differently  implemented  base.  Support 
center  personnel  are  taxed  by  the  requirement  to  understand 
the  nature  and  subtleties  of  all  the  development  environments 
of  the  products  they  support.  Again,  no  economy  of  scale. 

A  major  mismatch  exists  between  the  DoD  community's  develop¬ 
ment  environments  and  DoD's  in-service  support  environments  in 
number,  in  kind,  and  in  tools.  This  mismatch  consumes  scarce 
critical  human  resources  and  does  not  support  portability  of 
people  among  projects. 
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2.5  DEFENSE  EMBEDDED  COMPUTER  SYSTEMS 

Virtually  every  system  in  the  current  or  planned  inventory 
makes  extensive  U3e  of  computer  technology.  Computers  are 
integral  to  our  strategic  and  tactical  systems.  They  control 
the  targeting  and  flight  of  missiles,  they  coordinate  and 
control  the  sophisticated  systems  of  high  performance  aircraft, 
they  are  at  the  heart  of  the  defense  of  carrier  battle  groups, 
and  they  integrate  the  complex  activities  of  battlefield  command. 
The  software  of  these  computers  operating  in  real  time  performs 
both  component  control  functions  and  the  integration  functions 
of  inter-component  communication  and  control.  In  a  large  sense 
the  software  is.  the  system.  Potentially  a  system  function 
embodied  in  software  may  be  modified  to  improve  the  weapon 
system  capability  or  meet  new  threat  characteristics.  The 
computer  resources  —  hardware  and  software  —  are  inextricably 
part  of  a  larger  system  and  are  in  reality  subsystems  embedded 
in  the  system.  Such  computer  hardware  and  software  are  called 
embedded  computer  systems  (ECS)  or  embedded  computer  resources 
(ECR).  Defense  embedded  computer  systems  are  qualitatively 
different  than  other  uses  of  computers!  These  systems  have  the 
following  characteristics: 

a.  Although  not  all  systems  are  large,  all  are  very  complex 
Many  are  extremely  large.  Single  unified  systems 
of  1,000,000  lines  of  code  are  commonplace. 


b.  Most  ECS  systems  operate  in  real  time.  ECS  are 
required  to  respond  in  milliseconds  to  a  complex 
threat.  They  operate  on  sensor  data  and  provide 
controls  of  high  performance  aircraft  and  missiles. 

c.  Many  defense  ECS  systems  have  the  property  of 
catastrophic  consequence  of  failure.  Examples  are 
air  defense  and  ballistic  missile  warning  systems 
and  nuclear  weapon  command  and  control  systems, 

d.  There  is  intense  human  interaction  with  many  ECS 
such  as  command  and  control  systems  where  decision 
mechanisms  are  shared  by  operators  and  in  flight 
systems  where  the  ECS  responds  to  and  assist  the 
pilot  in  aircraft  control. 

e.  Defense  ECS  have  long  lives.  Some  may  be  operational 
for  20  years  of  more. 

f.  During  the  life  of  the  ECS,  it  must  be  able  to  be 
modified  and  adapted  to  meet  new  threats,  accommodate 
new  weapons,  operate  in  changing  operational  scenarios 
and  tactical  roles. 

g.  Most  ECS  applications  in  the  DoD  are  designed  and 
developed  for  the  first  time  by  the  DoD.  Defense 
agenc;  as  require  that  the  state-of-the-art  in  weapon 
systems  be  punned . 
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The  above  can  be  summarized  in  part  by  the  following  state¬ 
ments: 

a.  DoD  use  of  embedded  computer  resources  define  the 
extreme  ends  of  the  characteristics  listed  above. 

These  systems  push  the  state-of-the-art  in  applica¬ 
tions.  No  commercial  use  of  computers  hits  the  ex¬ 
treme  ends  of  all  of  the  characteristics  above  as 
consistently  as  do  DoD  systems. 

b.  DoD  requirements  leads  the  way  in  most  ECS  technology 
applications,  just  as  the  DoD  leads  in  research  and 
technology  application  of  jet  propulsion,  and  large 
jumbo  aircraft.  The  fallout  to  industry  follows  in 
commercial  systems  applications. 

Many  companies  develop  computer  resources  —  computer 
hardware  and  software  —  for  DoD  applications  as  well  as  for 
commercial  applications.  However,  few  spend  significant  funds 
for  computer  resource  technology  development  and  transition  to 
meet  the  demands  of  military  systems.  Their  R&D  concentration 
is  in  the  larger  commercial  market  where  the  investment  leverage 
is  greater,  specific  efforts  must  be  aimed  at  the  singular 
DoD  MCCR  (Mission  Critical  Computer  Resources)  and  ECR  (Embedded 
Computer  Resources)  software. 


2.6  THE  ADA  PROGRAMMING  SUPPORT  ENVIRONMENT 


The  Ada®*  Program,  serving  as  a  cornerstone  for  the  STARS 
Program,  has  defined  the  concept  of  an  Ala  Programming  Support 
Environment  (APSE),  It  is  built  upon  common  interfaces  and  data 
representations  for  automated  tools.  This  APSE  concept  is  being 
adopted  by  all  three  Services  to  aid  in  the  development  and 
support  of  Ada-based  software.  The  Services  are  committed  to 
consistency  in  the  Kernel  APSE  to  permit  tool  sharing. 

The  Ada  Program  developments  are  directed  to  the  computer 
programming  process.  However,  the  APSE  concept  provides  a 
basis  for  further  development  of  a  shared  environment  of  tools 
supporting  signficantly  more  of  the  software  engineering  process. 

2.7  ASSUMPTIONS 

The  SEX  is  proposed  as  the  vehicle  to  redress  the  problems 
of  technology  transition.  The  plan  for  the  SEI  is  based  on 
the  following  assumptions: 

a.  In  order  to  fully  realize  the  objectives  of  the 
STARS  program,  a  mechanism  for  technology  transition 
is  required. 

b.  The  problem  of  technology  transition  cannot  be  solved 
fast  enough  within  the  current  DoD  organizational 
structure  or  funding. 

*  Ada  is  a  trademark  of  the  U.S.  ’overnmer t  (AJPO) 
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c.  ECS  software  development  exhibits  characteristics 
not  usually  encountered  in  commercial  ADP  software. 
Industry  and  academia  are  concentrating  on  ADP 
technology,  not  as  much  on  ECS  technology.  The 
DoD  will  take  advantage  of  gains  provided  by  these 
commercial  efforts.  They  will  be  used  by  DoD 
when  applicable  and  engineered  for  use  by  the  SEI, 
but  they  will  not  be  enough, 

d.  To  ensure  that  the  problem  is  defined  properly  and 
addressed  for  all  of  the  DoD  ECS  community,  the  main 
mechanism  for  transition  -  the  SEI  -  should  be  funded 
by  and  should  be  under  the  control  of  DoD. 

e.  Ada  will  be  widely  accepted  and  the  kernel  APSE-based 
support  environment  will  serve  as  a  powerful  vehicle 
for  technology  integration  and  delivery, 

f.  The  DoD  has  a  large  Investment  in  assembly- level 
language  software  and  in  high-order-language  (other 
than  Ada)  software  that  will  be  in  the  operational 
inventory  for  some  time  to  come  --  10  to  20  years. 

This  software  may  be  supported  more  efficiently  if 
new  technology  is  brought  to  bear  where  practical. 

g.  A  significant  investment  of  resources  over  an  extended 
period  will  be  required. 
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Success  will  depend  on  the  cooperative  involvement 
of  researchers,  industry,  and  DoD  software  organizations. 


h . 
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3.0  MISSION,  OBJECTIVES,  FUNCTIONS  AND  GENERAL  DESCRIPTION 

OF  THE  SOFTWARE  ENGINEERING  INSTITUTE 

The  Software  Engineering  Institute's  Mission  is  to  improve 
the  state-of-the-practice  of  software  engineering  in  the  DoD 
community.  Specifically,  the  Institute  is  to  be  established  to 
bridge  the  gap  between  software  technology  development  and  appli 
cation.  The  gap  is  between  advanced  development  and  production 
in  a  classical  systems  acquisition  life-cycle  sense  and  the 
bridge  is  defined  as  engineering  development. 

To  accomplish  the  mission  stated  above,  the  SEI  has  four 
object  ives. 

o  First,  the  SEI  will  assimilate  software  technology 

advances  from  the  DoD  technology  base  and  other  sources. 

o  Second,  the  SEI  will  engineer  appropriate  tools,  methods 
and  techniques  and  supporting  technology  to  function 
efficiently  in  the  DoD  software  environments. 

o  Third,  it  will  support  the  effective  transition  and 
application  of  software  engineering  technology  to 
DoD  system  development  and  support. 

o  Fourth,  the  SEI  will  perform  research  in  methods  and 
tools  supporting  its  assimilation,  engineering,  and 
transition  activities. 


3.1  PRIMARY  FUNCTIONS  OF  THE  SOFTWARE  ENGINEERING  INSTITUTE 

The  four  objectives  translate  into  fifteen  SEI  functions  as 
shown  in  Figure  1,  Those  are  the  basic  functions  required  to 
carry  out  the  objectives  to  meet  the  mission.  Additional  func¬ 
tions  or  activities  may  also  be  carried  on  at  the  Institute.  Some 
of  these  are  described  in  section  3.2. 

Key  to  the  functioning  of  the  Institute  will  be  its  software 
environment.  This  environment  must  provide  the  technology  basis 
and  interface  standards  for  the  Services  to  derive  Service 
standard  environments.  The  Institute's  environment  will  be 
easy  to  port  to  other  sites,  and  can  3erve  as  the  basis  for 
value  added  efforts  by  others.  Maintained  by  the  institute, 
it  will  be  the  most  advanced  environment  as  the  Institute 
integrates  the  newest  technology  into  it.  A  KAPSE-based 
environment  will  be  the  standard  as  soon  as  practical. 

3.1.1  The  Functions  of  Assimilation 

The  Institute  will  foster  the  identification  and  evaluation 
of  valuable  new  technologies  in  several  ways.  First,  it  will  pro¬ 
vide  a  "laboratory"  for  the  experimental  evaluation  of  utility 
and  the  comparison  of  alternatives.  This  laboratory  will  have, 
as  its  basis,  a  support  environment  through  which  new  technology 
can  be  embodied  as  tools  and,  in  this  form,  be  applied  to  both 
experimental  and  real  problems.  Second,  the  Institute  will 
encourage  the  development  of  metrics  for  assessing  the  utility 
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of  aids.  Finally,  the  Institute  will  encourage  the  collection 
and  cataloging  of  data  from  alternative  aids. 

3.1.2  The  Functions  of  Engineering 

New  technology  developments  require  engineering  development 
effort  following  initial  proof  of  feasibility.  New  tools  need 
to  be  interfaced  to  the  environment  in  which  they  are  to  be 
used.  Proposed  new  techniques  may  need  to  be  modified  to  work 
in  an  environment  different  from  the  one  where  they  were 
developed.  After  integration,  these  tools  and  techniques  must 
be  documented  and  training  material  must  be  developed  to  assist 
in  their  introduction  into  a  user's  environment. 

The  Institute  will  select  advanced  tools  and  techniques 
and  integrate  them  into  its  environment.  In  accomplishing  the 
engineering  integration  task,  it  will  attempt  to  engineer  each 
new  tool  so  it  is  consistent  with  evolving  systems  interface 
Standards  so  they  can  be  integrated  into  service  standard 
environments  as  easily  as  possible. 

This  engineering-integration  function  will  be  paralleled 
by  the  constant  evaluation  of  the  SEI's  advanced  environment, 
the  Service's  environments  and  industry  environments  where 
the  institute's  tools  are  to  be  applied.  The  Institute's 
environment  will  evolve*  however,  its  evolution  will  be 
influenced  by  these  other  environments.  The  Institute's 
environment  must  always  remain  an  effective  vehicle  for 
transition  of  new  tools  to  the  user  environment. 
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3.1.3  The  Functions  of  Transition 


The  Institute  will  advocate,  assist,  train,  and  provide 
follow-on  support  to  effectively  transition  new  tools  and  tech¬ 
niques.  The  Institute  will  be  uniquely  able  to  advocate  its  new 
environment-integrated  tools  and  techniques.  The  Institute  will 
have  focused  on  the  practical  needs  when  searching  among  new 
technology  developments  for  solutions.  Utility  demonstration, 
both  in  and  outside  the  Institute,  will  add  confidence  to  new 
tools  to  be  transitioned. 

The  Institute  will  provide  assistance  and  training  to 
Service  organizations  to  facilitate  transition.  The  Services 
will  in  turn,  effect  transition  from  their  support  system  stan¬ 
dardization  organlzaitons  to  their  system  development  contractors. 
The  Institute  will  provide  limited  support  directly  to  a  contractor 
site  when  requested  by  the  appropriate  Service  organization. 

3.1.4  The  Functions  of  Research 

The  Institute  will  conduct  research  in  support  of  its 
primary  activities  of  assimilation,  engineering,  and  transition. 

The  major  research  focus  will  be  on  software  environments. 

Since  an  advanced  environment  will  be  the  vehicle  for  technology 
integration  and  transition,  the  Institute  will  conduct  continuing 
research  in  this  area  to  ensure  it  maintains  the  most  advanced 
production  environment  feasible.  Related  research  will 
investigate  methods  of  defining  interfaces  for  the  integration 
of  existing  tools. 
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Other  important  research  tasks  of  the  Institute  will  be 
directed  to  better  cataloging  of  software  system  functional 
components,  the  sociological  and  psychological  aspects  of 
transition,  and  metrics  for  evaluating  new  technologies.  The 
results  of  these  tasks  will  be  important  to  the  successful 
operation  of  the  Institute. 

3.2  TRAINING  AND  OTHER  FUNCTIONS 

In  addition  to  the  primary  functions  of  the  SEI,  it  will 
provide  training  and  professional  services.  These  activities 
will  enhance  the  role  of  the  Institute  as  a  transition  agent. 

The  Institute  will  educate  about  200  educators  per  year. 

The  education  provided  will  be  on  a  graduate  level.  New 
state-of-the-practice  tools  and  research  results  will  be 
taught.  Languages  and  computer  science  are  undergraduate 
efforts  and  will  not  be  taught. 

The  Institute  also  will  provide  training  on  the  installation 
and  use  of  its  advanced  environment  and  other  products.  This 
training  will  include  courses  in  methods,  tool  useage,  product 
tailoring  and  installation. 

Professionals  could  be  added  to  the  Institute  staff  and 
supported  on  a  fee-for-service  basis,  similar  to  the  manner 
in  which  75  people  are  employed  at  the  Federal  Computer  Perfor¬ 
mance  and  Simulation  Center  in  Washington,  D.C.,  called  Fed-Sim. 


Projects  and  entities  separate  from  the  Institute  will 
buy  consultation  or  services  from  the  Institute  and  pay  for 
those  services  on  an  as-used  basis.  (Such  work  by  the  Institute 
staff  provides  an  excellent  method  of  staying  in  touch  with  the 
state-of-the-pract ice  of  software  engineering.)  The  use  of  this 
support  device  would  not  be  limited  to  supporting  DoD  only,  nor 
government  agencies  only,  although  they  would  be  the  major 
focus . 

Use  of  the  Institute's  advanced  environments  on  a  service 
bureau  basis  will  generate  additional  resources. 

The  Institute  will  conduct  a  constant  review  of  software 
technology  and  practice  world-wide.  It  will  be  one  of  the  re¬ 
positories  of  DoD's  expertise  in  the  area.  With  the  intimate 
knowledge  of  its  in-house  showcase  environment  and  research,  a 
worldwide  review  of  research  and  practice,  and  a  connection  to 
the  rest  of  the  work  underway  in  the  STARS  effort,  the  Institute 
is  ideally  situated  to  perform  this  critical  role.  It  will  be 
a  national  resource  for  this  role  alone. 

3.3  OPERATIONAL  ENVIRONMENT 

The  operational  role  of  the  SEI  as  a  mechanism  for  technology 
transition  is  depicted  in  Figure  2.  Software  engineering  technology 
emerging  from  research  organizations  will  be  captured  by  the  SEI. 

The  primary  source  of  this  research  technology  will  be  DoD  labora¬ 
tory  projects  funded  both  by  on-going  Service  research  programs 
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Figure  2.  The  SEI  Transition  Role. 
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and  by  STARS.  Non-DoD  research  organizations  also  will  be  sources 
of  the  technology  captured  by  the  SSI .  The  research  technology 
will  be  integrated  and  packaged  by  the  SEI  and  the  resulting 
products  will  be  distributed  to  service  organizations  responsible 
for  standard  ECS  software  support  tools.  These  organizations, 
in  turn,  will  tailor  the  products  to  their  needs  and  distribute 
them  to  their  respective  software  development  and  in-service 
support  organizations.  The  products  will  be  made  available  to 
DoD  contractors. 

Since  the  SEI  will  have  limited  resources,  it  is  not  ex¬ 
pected  that  all  technology  insertion  will  occur  as  shown  in 
Figure  2.  The  Services  and  DoD  contractors  will  continue  to 
integrate  research  technology  from  the  DoD  laboratories  and 
other  sources  into  their  operational  support  systems  as  the 
need  arises. 

Within  the  SEI,  operations  can  be  viewed  as  a  pipeline  for 
the  evaluation,  integration,  and  delivery  of  software  engineering 
technology.  Figure  3  provides  a  simplified  view  of  the  SEI  internal 
organization.  The  Research  Division  (rd)  initializes  the 
pipeline  by  selecting  promising  technology  for  evaluation. 

That  technology  that  passes  the  RD  evaluation  filter  is  passed 
to  the  Outreach  Division  (ORD)  for  packaging  and  integration. 

ORD  establishes  a  project  for  packaging  and  integration.  Pilot 
evaluation  in  a  real  project  environment  also  may  be  attempted. 

The  Products  Division  (PD)  personnel  will  be  included  in  the 
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Figure  3:  A  Representation  of  the  Internal  Organization  of  the  SEI 


integration  activity,  pd  will  ensure  the  technology  meets 
packaging  and  integration  standards  and  then  release  the  technology 
to  the  DoD  community  in  a  support  environment.  PD  will  provide 
training  support  to  the  Services.  The  Operations  Division  (OD) 
will  support  the  pipeline  activities  with  computer  and  communi- 
ations  equipment  and  systems  engineering  expertise,  if  required. 

The  performance  of  the  SEI  in  meeting  it3  technology  objec¬ 
tives  will  be  continually  evaluated  and  the  results  will  be 
presented  to  OUSD  (R&AT)  management  periodically  (quarterly  or 
annually).  This  process  is  shown  in  Figure  4.  The  objectives 
set  in  the  SEI  Operations  Plan  will  be  reviewed  and  approved  by 
OUSD(RSAT)  management  before  the  start  of  the  plan  period.  Once 
the  plan  is  implemented  by  the  SEI  divisions,  the  Operations 
Division  will  have  the  responsibility  of  collecting  effective¬ 
ness  measure  data  and  preparing  performance  reports  for  SEI 
management.  The  data  might  include  resource  utilization  against 
plan,  number  of  projects  passed  from  Research  to  Outreach, 
number  of  pilot  project  transition  successes,  etc.  SEI  management 
might  redirect  the  Divisions  based  on  review  of  the  reports. 
Quarterly  and/or  annually,  the  SEI  performance  record  will  be 
presented  to  OUSD(RSAT)  management.  OUSD(RSAT)  management 
might  redirect  the  SEI  based  on  the  information  presented. 
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Figure  4.  SEI  Performance  Evaluation 
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3.4  SEI  DIVISION  ACTIVITIES 


A  more  detailed  discussion  of  the  functions  and  activities 
o£  the  SEI  divisions  follows  in  sections  3.4,1  through 
3.4.4. 


3.4.1  Research  Division 

The  Research  Division  ( RD)  has  four  important 
functions.  The  first  is  to  maintain  an  up-to-date  picture  of 
research  activities  related  to  software  engineering.  The 
second  is  to  evaluate  promising  technology.  The  third  is 
to  nominate  technologies  as  candidates  for  Outreach  project 
initiation.  The  fourth  is  to  conduct  research  in  metrics/ 
testing,  technology  insertion,  and  cataloging  of  software. 

An  up-to-date  status  of  software  engineering  technology  research 
will  be  published  semi-annually.  Research  projects  worldwide 
in  academia,  government,  and  industry  will  be  addressed.  The 
majority  of  information  will  be  collected  through  surveys 
and  literature  searches,  other  sources  will  include  the  DoD 
independent  Research  and  Development  (IRAD)  Program  and 
professional  conferences.  The  information  will  be  electronically 
encoded  for  access  via  the  ARPANET. 

On  a  continuing  basis,  RD  will  evaluate  the  research 
technology  survey  data  to  identify  technology  that  has  near-tarm 
practical  payoff  potential.  This  process  will  be  based  on  the 
following  criteria! 
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a.  State  of  development  -  the  technology  must  be  at  a 
stage  of  development  which  is  sufficiently  stable 
for  transition. 

b.  Applicability  to  DoD  -  the  technology  must  have 
aplicability  to  the  development  or  support  of  DoD 
embedded  computer  systems. 

c.  Payoff  -  the  technology  must  offer  the  potential  for 
significant  payoff  in  terms  of  increased  productivity, 
reliability,  or  quality. 

d.  Successful  transition  -  the  probability  of  success 

of  transition  must  be  commensurate  with  the  potential 
payoff. 

e.  Title  to  rights  -  there  must  be  no  encumbrances 
regarding  the  rights  of  the  DoD  community  (including 
DoD  contractors)  to  utilize  the  technology. 

f.  Cost  -  the  cost  of  packaging,  integration,  transition, 
and  life  cycle  support  must  be  commensurate  with  the 
potential  payoff. 

g.  Personnel  availability  -  the  personnel  required 
to  man  the  related  ORD  project  must  be  available. 

This  process  will  require  that  part  of  the  staff  perform  field 
activities  to  evaluate  technology  where  the  research  is  being 
conducted.  Grants  may  be  sponsored  by  RD  to  fund  the  evaluation 
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of  certain  technologies.  Some  projects  in  this  Division  will 
be  in  direct  support  (on-site)  of  ongoing  DoD  projects,  perhaps 
in  a  V&V  role. 

On  the  basis  of  the  filtering  evaluation  process,  promising 
technologies  will  be  identified.  RD  will  rank  these  technologies 
againist  those  currently  being  addressed  by  ORD  and  against 
internal  SEI  research  projects  concerning  transition  and  inte¬ 
gration.  Based  on  the  results  of  the  ranking,  certain  technol¬ 
ogies  will  be  nominated  for  ORD  project  initiation.  These 
nominations  will  be  factored  into  the  SEI  planning  process  by 
SEI  management*  Other  factors  considered  will  be  the  Product 
Division  product  development  plan  and  assessment  of  DoD  needs. 

The  RD  will  conduct  research  in  support  of  its  mission. 

This  research  will  include  methods  of  cataloging  software 
system  functional  components,  the  sociological  and  psychological 
aspects  of  transition,  and  metrics  for  evaluating  new  technologies 
The  results  of  these  tasks  will  be  important  to  the  successful 
operation  of  the  Institute. 

3.4.2  The  Outreach  Division 

The  Outreach  Division  (ORD)  primarily  will  be  responsible 
for  the  initiation  and  management  of  projects.  Most  of  the 
projects  will  be  concerned  with  the  packaging  of  new  technology 
and  its  integration  with  the  support  environment.  Projects 
also  may  be  addressed  to  technology  evaluation,  or  research 
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into  transition  aids  and  technologies.  Some  of  this  evaluation 
will  occurs  through  technology  trials  on  DoD  production  projects. 

Each  year,  as  part  of  the  planning  process,  on-going 
projects  will  be  evaluated  and  ranked  against,  new  technologies 
nominated  by  RD.  Based  on  this  planning  activity,  the  projects 
for  the  coming  year(s)  will  be  proposed.  This  may  involve 
cancellation  of  on-going  projects  which  are  not  progressing 
satisfactorily.  The  evaluation  of  on-going  projects  will  be 
based  on  the  projected  technical  objectives  and  the  project 
plan.  Measurements  against  these  objectives  and  the  plan 
will  be  made  throughout  the  year  to  give  SEI  management  a 
clear  picture  of  progress. 

The  project  teams  will  be  manned  by  visiting  scientists, 

SEI  permanent  staff,  and  support  contractors.  The  nucleus  of 
a  project  will  be  manned  by  the  visiting  scientists.  Ideally, 
the  project  leader  will  be  a  leader  in  the  field  of  software 
engineering  and  active  in  research  in  the  technology  area 
that  is  the  focus  of  the  project.  He  will  be  supported  by 
visiting  professionals  from  the  Services  and  industry  who 
have  proven  skills  in  software  engineering.  Project  management 
support  will  be  provided  by  the  SEI  permanent  staff.  For 
large  projects,  additional  technical  support  will  be  provided 
by  Products  Division  and  support  contractors. 
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When  visiting  scientists  and  professionals  complete 
their  term  with  the  SEI,  they  will  become  powerful  instruments 
of  transition  by  spreading  in  their  parent  organization  the 
software  engineering  techniques  and  approaches  learned  at 
the  SEI. 

In  some  cases,  it  may  not  be  possible  to  get  the  lead 
scientist  required  for  a  project  to  attend  the  SEI.  Under 
the  right  circumstances,  the  project  might  be  sponsored  under 
an  SEI  grant  to  the  parent  organization  of  the  individual. 

In  this  case,  evaluation  would  be  performed  under  the  same 
ground  rules  used  for  the  ORD  internal  projects. 

3.4.3  Products  Division 

The  Products  Division  (PD)  will  be  responsible  for 
product  development  support  and  delivery.  The  primary  product 
of  PD  will  bo  an  advanced  support  environment,  however  any 
tool  integrated  in  the  environment  could  itself  be  treated 
as  a  product  that  could  be  integrated  by  the  Service  with  any 
KAPSE-based  ( Kernel  APSE)  environment.  Standalone  products  - 
techniques  or  tools  -  also  may  be  offered  by  PD. 

The  product  repertoire  of  the  SEI  will  be  redefined 
periodically  in  a  product  planning  process.  Product  planning 
will  be  a  subactivity  of  the  SEI  strategic  planning  process. 
The  objective  of  the  product  planning  activity  will  be  to 
balance  the  ORD  project  activities  with  the  pressing  software 
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engineering  needs  of  the  DoD  community.  To  accomplish  this, 
three  things  are  needed.  First,  PD  must  be  continually  evaluating 
the  problems  facing  DoD  software  development  groups  to  identify 
areas  where  new  tools  can  improve  productivity  or  reliability. 
Second,  support  environment  enhancements  and  new  standalone 
products  which  will  address  the  needs  must  be  identified. 

Third,  the  ORD  project  plan  must  be  influenced  to  ensure  that 
the  needed  technology  is  packaged  and  integrated.  The  PD 
product  plan,  then,  will  be  a  result  of  both  demand  pull  and 
supply  push.  That  is,  both  the  needs  of  the  users  as  identified 
by  PD  and  the  availability  of  promising  technology,  as  identified 
by  RD  will  govern  the  product  packaging  and  integration  projects 
of  ORD.  These  in  turn  will  feed  the  new  product  releases  of  PD. 

The  PD  products  will  be  controlled  under  a  strict 
configuration  management  system.  Products  will  be  managed  in 
releases.  At  least  two  releases  will  be  under  configuration 
control  for  every  product  that  has  been  fielded  -  the  fielded 
release  and  the  next  release  under  product  development. 

Before  a  release  of  a  product  will  be  issued  it  will 
undergo  a  product  teat  and  quality  assurance  (QA)  process.  The 
QA  process  will  ensure  that  the  product  meets  SEI  standards  for 
programming,  documentation,  and  human  engineering.  Product 
test  will  ensure  the  correctness  ar»d  reliability  of  tha  release. 
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An  important  function  of  PD  will  be  customer  relations  and 
support.  PD  personnel  will  work  in  support  of  and,  in  some 
cases,  on  behalf  of  the  Services  in  generating  interest  and 
demand  for  new  software  engineering  tools  and  techniques  in  the 
end-user  community.  The  PD  personnel  will  also  provide  field 
support  for  installation,  conversion,  and  training. 

The  primary  training  provided  by  PD  will  be  courses  offered 
at  the  Institute  for  the  ECR  Service  organisation  personnel  re¬ 
sponsible  for  Service  Environment  support.  These  courses  will 
be  timed  to  coincide  with  new  product  releases  of  the  SEI.  They 
will  instruct  the  Service  representatives  on  the  installation, 
operation,  and  use  of  the  products.  The  use  instruction  will 
include  training  on  the  proper  application  of  associated  software 
engineering  methods.  Under  certain  circumstances,  the  PD  personnel 
will  provide  the  training  at  Service  or  DoD  contractor  sites. 

This  will  usually  occur  when  an  SEI  product  is  being  installed 
for  use  at  a  major  development  or  in-service  support  site. 

3.4.4  Operations  Division 

The  Operations  Division  (OD)  primarily  is  responsible 
for  the  maintenance  and  operation  of  the  SEI  data  processing 
services.  OD  will  be  capable  of  supporting  a  two-shift  opera¬ 
tion.  OD  personnel  will  be  capable  of  system  engineering 
and  systems  programming  support  to  the  other  Divisions. 
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Another  important  function  of  OD  is  measurement  data 
collection  and  reporting,  OD  will  collect  certain  measurement 
data  automatically ,  e.g.  front  project  management  status  files, 
and  others  will  be  collected  manually  and  be  keyed  into  machine 
readable  form.  Measurement  reports  of  various  types  will  be 
produced  periodically  for  SEI  management  from  the  data  base. 

The  Operations  Division  also  will  manage  a  limited  service 
bureau  operation  to  support  Services  or  DoD  contractor  organiza¬ 
tions  who  wish  to  use  the  SEI  resources  in  support  of  their  pro¬ 
jects.  A  development  project  office  may,  via  a  network,  send 
to  the  Institute  a  large  body  of  software  to  be  "run  through  a 
tool"  on  the  Institute's  computer  and  the  results  sent  back  out. 

Initially,  the  Institute  will  provide  this  service  at 
no  cost  to  Service-authorized  projects.  After  the  initial 
shake-down,  the  Institute  will  -  for  a  fee  -  provide  this 
service  to  Service-authorized  projects.  This  service  will 
help  to  keep  the  Institute  current  on  the  state  of  the  practice 
in  the  ECR  software  community. 

3.5  PERSONNEL 

In  order  to  accomplish  the  functions  described  in  section 
3.1,  the  Institute  will  be  staffed  with  some  of  the  best  software 
people  in  the  world. 

There  are  two  ways,  at  least,  to  attract  the  quality  of 
software  porfessionals  needed  -  i.e.,  the  very  best.  First, 


allow  them  to  do  original  and  interesting  research  in  a  well- 
supported  laboratory.  Second,  offer  the  chance  to  change  the 
state-of-the-pract ice  across  a  wide  part  of  the  field.  The 
Institute  will  do  both.  The  SEI  will  provide  an  environment 
which  will  attract  researchers  in  government,  industry,  and 
academia.  Some  researchers  will  be  offered  visiting  positions 
of  one  to  two  years  duration  to  evaluate,  package,  and  integrate 
technology  developed  under  his  or  her  previous  research  efforts. 

To  be  successful,  a  broad  range  of  skills  will  be  required 
in  the  Institute.  Skilled  researchers,  administrators,  product 
managers,  development  personnel,  educators,  and  public  relations 
personnel  are  just  some  of  the  diverse  skills  required.  The 
skills  and  experience  required  for  the  key  positions  are 
summarized  below. 

a.  Technical  Director  -  The  technical  director  will  be 
responsible  for  the  overall  management  of  the  SEI  including 
planning,  technical  direction,  financial  management,  and  hiring. 
This  will  require  sound  skills  in  business  management  and 
experience  in  operating  a  $5-10  million  enterprise.  The 
technical  director  snould  have  experience  in  managing  applied 
research.  He  should  be  familliar  with  the  structure  and 
management  procedures  of  DoD.  A  PhD.  in  a  computer-related 
discipline  is  desirable. 

b.  Administrative  Manager  -  The  administrative  manager 
(chief  of  staff)  will  report  to  the  technical  director.  He 
will  be  responsible  for  all  administrative  activities. 


He  must  be  a  skilled  manager  with  experience  in  finance,  contracts, 
personnel,  public  relations,  and  office  management.  His  educational 
background  should  include  an  MBA. 

c.  Planning  Specialists  -  The  planning  specialists  will 
report  to  the  technical  director.  They  will  be  responsible  for 
coordinating  the  SEI  strategic  and  operations  planning  process. 

They  must  be  experienced  planners  familiar  with  software 
technology  and  financial  analysis.  They  must  be  familiar  with 
the  operation  of  software  product  businesses.  Technical  degrees 
are  required. 

d.  Research  Division  Manager  -  The  RD  manager  will  report 

to  the  technical  director.  He  will  be  responsible  for  the  manning, 
planning  inputs,  and  direction  of  RD.  He  must  be  an  experienced 
manager  knowledgeable  in  the  field  of  software  engineering  tech¬ 
nology.  He  should  be  a  Ph.D.  in  computer  sciences  with  strong 
connections  in  the  world  of  software  engineering  R&D . 

e.  Outreach  Division  Manager  -  The  ORD  manager  will  re¬ 
port  to  the  technical  director.  He  will  be  responsible  for  the 
manning,  planning  inputs,  and  direction  of  ORD.  In  particular, 
he  will  be  responsible  for  recruiting  the  visiting  scientists 
who  will  lead  the  ORD  projects.  He  must  be  an  experienced 
manager  with  stror.g  background  in  the  management  of  applied 
research  irojects.  He  should  be  a  technologist  who  can  command 
the  rsspect  of  vi-iting  scientists. 
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f.  Outreach  Project  Leaders  -  The  leaders  of  ORD  projects 
will  report  to  the  ORD  manager.  They  will  have  responsibility 
for  the  management  and  technical  direction  of  their  projects. 

Since  not  all  lead  scientists  are  expected  to  be  capable  project 
managers,  professional  project  management  support  will  be  available 
from  the  ORD  permanent  staff.  The  project  leader  must  be  a  leader 
in  the  technology  area  which  is  the  focus  of  his  project. 

g.  Products  Division  Manager  -  The  PD  manager  will  report 

to  the  technical  director.  He  will  be  responsible  for  the  manning, 
planning  inputs,  and  direction  of  PD.  He  must  be  an  experienced 
manager  who  understands  software  product  development,  test,  and 
marketing . 

h.  Product  Development  Manager  -  The  product  development 
manager  will  report  to  the  Products  Division  manager.  He  will  be 
responsible  for  the  product  packaging  of  ORD  project  technologies 
and  for  the  support  of  the  SEX  support  environment  and  fielded 
tools.  He  must  have  a  solid  background  in  software  product 
development  and  support. 

i.  Product  Test  Manager  -  The  product  test  manager  will 
report  to  the  Product  Division  Manager.  He  will  be  responsible 
for  the  testing  of  product  releases  before  delivery  to  the  ser¬ 
vices.  He  must  have  a  solid  background  in  software  product 
testing . 
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j.  Product  Distribution  Manager  -  The  product  distribu¬ 
tion  manager  will  report  to  the  Products  Division  Manager.  He 
will  be  responsible  for  the  "mark* ;ing" ,  delivery,  installation, 
and  training  support.  The  "marketing"  responsibility  will  be  one 
of  providing  support  to  or  acting  on  the  behalf  of  the  Services 
in  advertising  the  benefits  of  the  available  products  and  in 
demonstrating  the  application  of  the  products.  The  distribution 
manager  should  be  very  knowledgeable  of  the  DoD  software  community 
and  experienced  in  sales  and  field  support. 

k.  Operations  Division  Manager  -  The  OD  manager  wi^.1  report 
to  the  technical  director.  He  will  be  responsible  for  the  manning, 
planning  inputs,  and  direction  of  OD.  He  must  be  experienced  in 
the  management  of  data  centers  supporting  product  development  and 
research  projects. 
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4.0  ISSUES  AND  ALTERNATIVES 


There  are  several  difficult  issues  in  regard  to  the 
creation  of  Software  Engineering  Institute.  Some  of  these 
issues  are: 

a.  What  is  the  scope  of  the  support  base  for  the 
Institute?  Should  it  be  directed  to  the  DoD  community  alone 
or  should  it  be  broad,  encompassing  the  needs  of  other 
government  agencies  and  industry? 

b.  How  should  the  Institute  be  managed?  Should  it  be 
managed  at  the  Office  of  Secretary  of  Defense  level,  by  a 
Tri service  group,  or  by  an  indu a try/government  consortium? 

c.  What  should  be  the  host  organization  mechanism? 

Should  it  be  hosted  in  the  government,  industry,  or  academia? 

d.  What  should  the  relationship  be  with  STARS?  Should 
the  Institute  perform  some  of  the  STARS  research? 

These  questions  are  key  to  the  successful  establishment 
and  operation  of  the  Institute.  The  following  sections 
discuss  these  issues  in  more  depth.  Alternatives  are  presented 
and  evaluated. 

4.1  SUPPORT  BASE 

The  scope  of  the  DoD  support  base  is  a  key  issue  in  that 
it  determines  the  management  approach  and  the  very  nature  of 
r  h*»  Institute.  If  the  support  base  is  limited  to  DoD  and 
iti  uoi: tractors,  then  it  is  natural  for  the  Institute  to  be 
managed  by  DoD  and  its  products  will  be  oriented  to  embedded 


-39- 


computer  systems.  If  the  support  base  is  broad,  including  DoD, 
other  government  agencies,  and  industry,  then  the  management  of 
the  Institute  should  represent  the  interests  of  all  three  and 
its  products  should  address  the  broad  range  of  problems  associated 
with  software  of  all  types. 

There  are  several  alternative  definitions  of  the  Institute 
support  base.  One  is  to  focus  on  the  embedded  computer  systems 
sub-community  of  the  DoD  community.  This  sub-community  is  of 
vital  concern  to  our  national  defense  due  to  the  importance  of 
embedded  computer  systems  to  modern  weapon  systems.  The  Institute 
must  serve  this  group  at  the  least.  Another  alternative  is  to  direct 
the  institute  to  the  support  of  all  government  groups.  The 
broadest  alternative  would  direct  the  Institute  to  the  support 
of  government  and  industry. 

Four  considerations  are  important  in  evaluating  the  alternatives 
for  the  support  base.  One  is  the  difference  between  embedded 
computer  software  and  other  software.  The  second  is  the  focus 
of  current  industry  activities  in  software  technology.  The 
third  is  the  differing  resource  levels  required  for  each 
alternative.  The  fourth  is  the  degree  of  assurance  that  DoD' a 
strategic  needs  will  be  satisfied. 

Embedded  computer  software  is  a  unique  class  of  software 
system  problem  demanding  a  level  of  engineering  discipline  and 
management  not  reequired  by  other  classes  of  software.  These 


large,  real-time,  complex  systems  require  a  different  level  of 
tooling  and  project  structure  than  that  required  for  business 
appplications .  To  date,  engineering  technology  research  has 
not  been  directed  to  the  solution  of  problems  faced  within  this 
class  of  software  system.  For  this  reason,  it  is  imperative 
that  the  Institute  assure  the  application  of  sufficient  resources 
to  this  class  of  software  as  its  first  priority. 

Most  of  the  technology  development  in  industry  is  aimed  at 
the  commercial  computer  applications.  Because  embedded  computer 
systems  are  a  small  fraction  of  this  marketplace,  little  emphasis 
is  being  placed  on  them.  On  the  other  hand,  it  would  be  a  waste 
of  resources  for  the  Institute  to  focus  on  the  predominant 
commercial  application  classes  since  this  would  duplicate  the 
efforts  of  industry  which  has  adequate  impetus  from  market  forces. 

There  will  be  a  tremendous  difference  in  the  resource 
requirements  of  the  Institute  depending  on  the  support  base 
alternatives  chosen.  It  would  be  a  challenge  to  successfully 
integrate  and  transition  technology  in  the  relatively  narrow 
DoD  embedded  computer  sub-community.  Here  the  scope  of  technology 
can  be  defined  and  the  channels  for  technology  transition  are 
circumscribed.  For  the  broad  case  of  all  government,  or 
government  and  industry,  the  technology  integration  would  address 
all  classes  of  software  and  the  technology  transition  channels 
would  be  unmanageably  large.  It  is  unlikely  that  the  difficult 
goal  of  accelerated  technology  transition  can  be  accomplished 
in  the  broader  contexts, 


Given  the  breadth  of  software  systems  and  the  diverse 
nature  of  software  production  in  government  and  industry,  it  is 
unlikely  that  the  critical  needs  of  DoD  in  the  embedded  computer 
arena  will  get  the  necessary  attention  if  the  Institute  addresses 
all  of  government  or  government  and  industry  as  its  support 
base.  Unless  the  Institute's  resources  are  focused  exclusively 
on  the  difficult  problems  of  embedded  computers,  the  efforts  of 
the  Institute  will  gravitate  to  the  more  manageable  problems 
characterising  commercial  applications. 

Based  on  the  foregoing  considerations,  the  following 
conclusions  are  drawn: 

a.  The  support  base  for  the  Institute  should  be  limited 
to  the  embedded  computer  system  sub-community  of  DoD. 

b.  Advantage  should  be  taken  of  the  technology  innovations 
of  industry  in  non-embedded  applications  by  scaling  it  up. 

c.  The  advances  offered  by  the  Institute,  although  targeted 
to  DoD,  should  be  made  available  to  other  governmwent  agencies 
and  industry. 

By  focusing  the  Institute  on  the  DoD  embedded  systems  sub- 
community,  the  strategic  needs  of  DoD  will  be  satisfied.  Because 
embedded  systems  represent  the  most  complex  of  software  systems, 
technology  developed  to  support  them  will  provide  leading-edge 
spin-off  into  other  classes  of  software  much  as  the  technology 
used  for  manned  spaceflight  has  found  its  way  into  the  home. 

The  Institute  products  will  be  useful  to  other  Government  agencies 
FAA,  NASA,  etc,  who  have  embedded  computer  systems. 
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4 . 2  MANAGEMENT 


The  management  control  of  the  Software  Engineering 
Institute  must  be  assigned  such  that  the  objectives  of  the 
Institute  will  be  met.  The  decision  on  where  to  assign 
the  management  responsibility  is  determined  to  some  degree  by 
the  support  base  decision.  If  the  support  base  is  all  of 
government  and  industry,  then  a  government/industry  consortium 
might  be  the  best  approach.  If  the  support  base  is  primarily 
DoD,  the  the  management  of  the  Institute  should  reside  within 
DoD. 


In  section  4.1  it  was  argued  that  the  Institute  should 
support  the  embedded  computer  sub-community  of  DoD.  This 
suggests  that  the  management  of  the  Institute  should  be  with 
DoD.  Two  alternatives  seem  reasonable.  One  is  to  manage  the 
Institute  at  the  level  of  OSD  through  the  STARS  Joint  Program 
Office.  This  alternative  is  described  in  the  remainder  of  this 
section.  The  alternative  is  to  delegate  the  management  to  a 
Tri-Service  group.  This  alternative  is  described  in  Section  3. 

To  ensure  coordination  with  the  STARS  program,  the  funding 
f<  r  the  group  should  flow  through  the  STARS  Joint  Program  Office 
in  coordination  with  the  STARS  Revire  Committee  (which  is 
composed  of  the  STARS  Director,  the  SEI  Coordinator  and  the 
three  Service  Program  Managers).  It  also  will  be  valuable  to 


-4  3- 


include  other  government,  industry,  and  academic  guidance  in 
the  management  of  the  Institute.  This  can  be  accomplished 
through  a  senior  board  of  visitors.  In  addition,  a  technical 
interest  group  composed  of  DoD  laboratory  personnel  and 
Service  ECS  environment  users  would  provide  advice  to  the 
management . 

The  major  components  and  relationships  regarding  the 
management  of  the  Institute  are  shown  in  Figure  5.  The  CSS, 
under  DUSD  ( R&AT)  will  have  DoD  responsibility  for  STARS  and 
the  Software  Engineering  Institute.  The  STARS  Review 
Committee  will  manage  the  SET  in  a  programmatic  sense,  setting 
objectives,  controlling  funding,  approving  budgets,  and  reviewing 
results.  The  SEI  coordinator  will  manage  the  SEI  Contract  and 
provide  the  essential  interface.  The  board  of  visitors  will 
review  technical  plans  and  accomplishments  of  the  Institute. 

It  will  make  recommendations  to  the  STARS  Review  Committee 
regarding  technical  direction  of  the  Institute.  The  Service 
laboratories  and  environment  users  will  have  a  close 
relationship  with  the  Institute  through  the  technical 
interest  group.  This  relationship  may  include  joint  projects 
personnel  exchange,  and  planned  information  exchange. 
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DOSD(RSAT) 


Figure  5:  SEI  Management  and  Relationships 


4.3  HOST  ORGANIZATION 

Where  to  host  the  Institute  is  a  difficult  question,  because 
there  are  many  reasonable  alternatives.  The  choice  will  depend 
on  a  number  of  factors  which  bear  on  the  success  of  the  Institute. 

The  alternatives  considered  are  to  delegate  the  responsi¬ 
bility  to  a  Service,  to  set  up  an  internal  DoD  program  office, 
to  contract  with  a  private  corporation  to  perform  the  responsi¬ 
bility,  to  establish  the  Institute  in  a  Univeriaty  setting, 
or  to  set  up  or  contract  with  a  non-profit  corporation. 

The  chief  criteria  used  to  differentiate  the  alternatives, 
in  the  order  of  decreasing  importance,  were  the  following: 

a.  DoD  Needs  -  will  the  BCR  system  needs  of  DoD  and  the 
resultant  software  technology  tools  get  first  priority? 
This  will  be  the  case  if  the  goals  and  incentives  of 
the  organization  are  fully  directed  to  the  needs  of 
the  DoD  community.  Any  goals  or  incentives  not  so 
oriented  may  cause  a  confusion  of  aims  in  this  very 
advanced  area. 

b.  Effective  Transition  -  will  effective  transition 
channels  be  established  with  the  Services?  Each 
Service  has  an  established  organizational  structure 
including  groups  performing  software  technology 
research  and  transition.  The  SEI  must  create  effective 
communications  with  the  Services  (and  DoD  contractors) 
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without  duplicating  the  established  organizations  or 
confusing  the  flow  of  their  effort. 


c.  Personnel  -  will  the  best  talent  in  the  software 
engineering  community  be  attracted?  The  SEI  must 
provide  an  environment  that  is  attractive  to 
technologists  and  practitioners  -  good  facilities, 
proximity  to  other  technologists  in  the  field,  an 
atmosphere  that  rewards  creativity  and  accomplishment, 
and  a  chance  to  make  an  impact. 

d.  Cooperation  -  will  the  cooperation  of  government, 
industry,  and  academia  be  assured?  The  success  of 
the  SEI  will  depend  on  this  cooperation  as  both  a 
source  and  sink  for  new  technology,  and  as  a 
source  of  visiting  scientists.  The  SEI  must  have 
the  means  to  nurture  this  cooperation. 

The  Service  alternative  was  rejected  because  it  is  unlikely 
that  one  Service  will  integrate  and  package  technology  in  a 
manner  generally  useable  by  all  the  Services.  Also,  the  existing 
shortage  of  software  engineering  professionals  in  the  Services 
would  be  further  aggravated  by  the  responsibility  to  man  an 
Institute.  It  is  unlikely  that  the  top  people  in  the  software 
engineering  community  can  be  attracted  to  a  service  run  operation 
of  this  type.  The  same  general  logic  applies  to  the  DoD  program 
office  alternatives. 
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A  contract  with  a  private  corporation  was  rejected  on  a 
possible  confusion  of  aims,  rights  to  the  products  and  a  per¬ 


ceived  conflict  of  interest  or  unfair  advantage  in  future 
competitions.  It  is  not  felt  that  an  entity  driven  by  the 
incentives  of  the  marketplace  will  consistently  place  the 
needs  of  DoD  in  a  position  of  number  one  priority. 

Both  a  University-based  Institute  and  a  non-profit 
organization  are  deemed  suitable  for  the  SEX.  The  University- 
based  Institute  is  attractive  because  it  offers  a  desirable 
atmosphere  for  technologists,  thus  enhancing  the  ability  to 
attract  first-rate  visiting  scientists.  The  proximity  to  an 
educational  institution  also  may  help  support  the  training 
role  off  the  SEI. 

A  University  seems  to  promise  a  good  magnet  for  the  top 
people  in  the  field  and  a  good  teaching  facility.  It  would 
bo  natural  to  expand  into  a  wider  training  role.  The  Institute 
must  be  free  standing  and  not  become  encumbered  by  University 
politics,  tenure  practices,  or  "publish  or  perish"  practices. 

Despite  these  advantages  of  a  University,  the  non-profit 
corporation  perhaps  teamed  with  a  University  or  Universities  is 
favored  because  of  its  strength  in  the  principal  activity  of  the 
Institute,  namely  transition.  The  role  of  software  engineering 
technology  packaging  with  product  quality,  the  long  term  support 
of  these  products,  and  their  distribution  are  not  familiar 
activities  of  a  Univerisity  where  the  orientation  is  more  in  the 
realm  of  research-quality  tools. 
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4.4  DISTRIBUTION  OF  THE  INSTITUTE 


The  discussion  in  the  previous  sections  have  centered  on  an 
Institute  operation  where  all  the  resources  of  the  Institute  are 
colocated.  An  alternative  to  this  is  the  geographic  distribution 
of  resources.  The  advantages  of  distributing  the  Institute  is  to 
provide  better  locality  to  the  pool  of  professionals  from  where 
the  Institute  will  be  manned  and  to  be  more  responsive  to  the 
community  the  Institute  will  serve.  The  disadvantages  are 
increased  costs  of  communication  and  potential  dilution  of 
already  scarce  human  resources. 

There  are  several  parts  of  the  Institute  that  can  be  separated 
and  distributed  without  difficulty.  The  activities  of  the  Research 
Division  are  such  that  it  can  be  separated  from  the  rest  of  the 
Inaititute  as  long  as  its  products,  e.g.  surveys  of  on-going 
research,  are  readily  available  to  the  remainder  of  the  Institute. 
This  can  be  accomplished  via  telecommunications.  The  projects 
of  the  Outreach  Division  are  good  candidates  for  distribution. 

This  may  be  a  necessity  if  the  Institute  is  to  get  the  cooperation 
of  the  top  people  as  visiting  scientists.  Product  installation 
and  training  support  teams  will  be  more  effective  if  they  are 
geographically  close  to  the  DoD  groups  they  serve. 

The  product  development  and  test  resources  should  not  be 
split  up,  To  get  the  most  out  of  the  resources  they  must  be 
concentrated  about  the  activity  of  advanced  software  engineering 


environment  support  and  integration  of  new  tools  with  this 
environment . 

The  above  discussion  suggests  a  configuration  for  a  distri¬ 
buted  Institute  consisting  of  three  types  of  centers  -  product 
center,  regional  centers,  and  local  projects.  The  product  center, 
which  may  serve  also  as  a  regional  center,  will  house  the  resources 
required  to  package,  integrate,  and  distribute  the  Institute  products. 
The  regional  centers  will  support  project  activities  of  Outreach 
and  the  product  installation  and  training  groups.  Local  projects 
might  reside  wherever  the  key  professionals  are  located,  e.g. 
Universities,  industry,  or  the  Services. 

The  research  division  and  the  Institute  management  and 
administrative  staff  might  reside  at  the  product  center  or  a 
regional  center.  The  operations  division  would  support  the 
product  center  and  the  regional  centers. 

In  order  for  such  a  distributed  organization  to  function 
effectively,  the  data  processing  resources  of  the  Institute 
should  be  distributed  in  the  product  center  and  the  regional 
centers.  A  communications  network  would  link  the  centers 
together.  Local  projects  would  access  the  Institute  DP  resources 
over  telecommunications  facilites  as  well  as  access  to  a  local 
network  of  computing  facilities. 


Whether  the  Institute  is  created  in  a  centralized  or 
distributed  organizational  configuration  it  will  have  to  support 
some  form  of  distributed  activity.  The  Institute'3  product-end- 
user  is  widely  spread  geographically.  Effective  distribution  of 
the  products  will  require  on-site  support.  Certain  Outreach 
projects  will  be  performed  where  the  key  professional  i3  located. 
Furthermore,  making  the  Institute  resources  available  on  a  pay- 
for-9ervice  basis  implies  remote  access  of  DP  facilities. 
Therefore,  even  in  the  case  of  centralized  resources,  distributed 
activities  must  be  supported  effectively. 
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5.0  EXPANDED  SEI  MISSION  AND  MANAGEMENT  ROLE 


The  Institute  is  part  of  the  STARS  program,  yet  it  is  to 
be  operated  and  managed  separate  from  the  STARS  research  projects. 
This  has  led  to  the  Institute's  mission  description  as  defined 
in  section  3.  An  alternative  approach  is  to  further  integrate  the 
Institute  with  STARS  in  such  a  way  that  the  Institute  manages 
some  or  all  of  the  STARS  research  areas.  Although  this  alternative 
would  not  necessarily  alter  the  alternative  choices  made  in  the 
previous  sections  it  would  add  some  complexity  to  these  issues. 

Service  managers  have  expressed  the  desire  for  more  Service 
involvement  in  the  proposed  management  of  the  STARS  Program  and  of 
the  Software  Engineering  Institute.  Tri-Service,  joint-Service, 
lead-service,  etc.,  schemes  ‘  sq  been  suggested  informally. 

This  section  offers  an  alternative  to  combine  the  management 
of  the  central  focus  of  the  STARS  Program  with  the  management  of 
the  Software  Engineering  Institute.  A  joint  DOD/tri-Service 
management  similar  to  that  of  the  DOD  Electromagnetic  Compatibility 
Analysis  Center  is  presented. 

5 . 1  Background 

The  STARS  Program  plan  central  thrust  is  the  engineering 
development  of  modern  software  development  environments.  These 
efforts  are  to  be  based  on  available  technology  and  provide  near- 
term  advanced  environments  with  respect  to  those  in  current  use. 
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Additionally,  the  environments  are  to ' be  able  to  accept  new 
elements  and  tools.  The  Ada  support  tools  (of  the  ALS  and  AIE) 
are  to  be  integrated.  These  STARS  projects  are  to  be  distributed 
among  individual  component  organizations. 

The  Software  Engineering  Institute  has  a  primary  function 
to  maintain  an  advanced  Software  Development  Environment.'  Its 
primary  function  is  to  engineer  new  technology  to  continuously 
improve  this  environment  and  provide  these  new  tools  to  Defense 
software  developers.  As  the  Institute  comes  into  existence 
(presumably  under  contract),  a  question  will  arise  as  to  the  source 

of  its  "first  model"  advanced  environment.  If  the  STARS  Program 

•« 

environment  projects  are  successful,  capabilities  from  one  or 
more  will  be  available  for  the  Institute. 

Since  the  Institute  is  to  maintain  ar.  evolving  advanced 
environment,  it  is  appropriate  to  consider  its  role  in  the 
development  of  the  STARS  advanced  environments.  Thus,  in 
addition  to  the  mission  as  described  in  section  3,  it  is 
recommended  that  the  SEI  assume  technical  management  and 
coordination  of  the  STARS  Program  core  projects,  namely 
to  develop  modern  software  life-cycle  engineering  environments. 

5 . 2  Organization  of  the  Expanded  Software  Engineering  Institute 

The  expanded  mission  of  the  Institute  will  require  a  resident 
cadre  of  DoD  technical  managers.  Figure  6  shown  an  organization 
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CONTRACT 


Figure  6s  SEI  Expanded-Mission  Organization 
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structure  which  could  support  the  expanded  SEI  functions.  This 
structure  is  modelled  after  the  Electromagnetic  Compatibility 
Analysis  Center  (ECAC),  which  is  summarized  in  section  5.5. 

Resident  members  of  the  three  Services  form  a  DoD  component  of 
the  SEI  to  manage  both  the  on-site  and  off-site  contracted 
efforts.  Army,  Navy  and  Air  Force  deputy  directors  and  their 
assistants  are  responsible  for  research  and  development  projects,  . 
initially  for  the  development  of  an  advanced  software  development 
environment,  later  for  environment  metrics  research  and  integration 
research. 

The  Service  deputies  assist  the  director  in  managing  the 
on-site  SEI  contractor,  They  provide  liaision  with  the  Services 
assuring  proper  interface  is  maintained  with  the  appropriate 
Service  elements.  They  assure  that  their  Services'  needs  are 
considered  in  the  Institute's  planning  and  programming.  They 
are  active  agents  in  the  understanding  of  the  state-of-the-pract ice 
shortcomings  and  needs,  and  in  matching  technology  state-of-the- 
art  to  these  needs.  They  are  influential  in  the  transitioning 
of  technology  to  the  institute  and  in  the  insertion  of  Institute 
engineered  and  integrated  tools  into  the  Defense  community. 

The  DoD  component  of  the  Institute  has  a  vital  role  in 
"selling"  the  new  products  of  the  Institute,  since  they  are 
involved  in  evaluating  and  understanding  the  Service  community 
needs,  each  representative  will  be  uniquely  able  to  assist 
in  the  insertion  of  new  tools  which  have  been  engineered  by  the 
Institute  to  meet  his  Service's  needs. 
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The  contractor  component  of  the  SEI  organizat ion  is  essentially 
the  same  as  described  previously.  Its  functions  are  unchanged. 

5. 3  Management  Relationships 

From  the  DoD  point  of  view,  the  participation  in  real  time 
and  closer  control  and  feedback  is  clearly  an  advantage.  The  DoD 
and  contractor  components  work  together  in  planning  and  in 
executing  the  SEI  mission  activities.  The  resident  service 
personnel  provide  a  credible  communication  link  to  each  of  the 
Services. 

From  the  contractor's  view,  the  close  proximity  of  DoD 
management  may  be  perceived  both  positively  and  negatively. 

Certainly  the  assistance  in  liaision  with  the  Defense  community 
is  a  positive  factor.  The  closer  control  exercised  may  well 
be  a  mutual  advantage,  rather  than  one  accruing  only  to  the 
Government . 

5 . 4  The  DoD  Electromagnetic  Compatibility  and  Analysis  Center 

The  DOD  Electromagnetic  Compatibility  Analysis  Center  (ECAC) 
was  established  in  1960  as  part  of  the  DOD  electromagnetic 
compatibility  (EMC)  program  wherein  the  Army,  Navy,  and  the  Air 
Force  were  assigned  specific  responsibilities.  The  Air  Force 
was  assigned  the  responsibilty  as  executive  agent  for  the 
management  of  ECAC. 
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The  joint-service  operated  Institute  receives  general 
guidance  and  direction  and  is  situated  within  the  Department  of 
Defense  as  illustrated  in  Figure  7.  Broad  policy  and  guidance 
is  provided  by  the  Chairman  Joint  Chiefs  of  Staff  and  the 
Assistance  Secretary  of  Defense  for  Research  and  Engineering, 
or  their  designees.  Plans  for  the  development  and  operation 
of  ECAC  are  subject  of  their  approval. 

A  DoD  Directive  prescribes  the  mission,  functions  and 

responsiblities  and  operational  relationships  and  management 

arrangements.  As  specified  by  the  directive,  the  ECAC  functions 

administratively  under  the  direction  of  the  Secretary  of  the 

* 

Air  Force.  Early  DoD  manning  of  ECAC  came  from  all  three 
Services.  Currently,  it  is  staffed  by  Air  Force  personnel. 

ECAC  is  the  DOD  focal  point  for  the  development  of  EMC 
analytical  capabilities.  ECAC  provides  advice  and  assistance  on 
EMC  matters  to  the  Secretary  of  Defense,  the  Joint  Chiefs  of 
Staff,  the  Military  Departments,  and  other  DOD  components. 
Engineering  support  services  are  provided  to  ECAC  by  a  contractor. 
The  government-contractor  team  provides  an  unequaled  technical 
resource  to  deal  with  the  myriad  EMC  tasks  confronting  the 
Department  of  Defense. 

The  Assistant  Secretary  of  Defense  (Telecommunications)  and 
the  Chairman,  Joint  Chiefs  of  Staff  or  their  designees  jointly 
provide  policy  guidance,  assign  projects,  and  establish  projects 
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Figure  7.  ECAC  Management 


priorities.  Plans  for  the  development  and  operation  of  the  ECAC 
are  subject  to  their  approval. 

DOD  Directive  5160.57  prescribes  the  mission,  functions, 
responsibilities,  operational  relationships,  and  the  management 
arrangement  for  the  joint  DOD  Electroraagni tic  Compatibility 
Analysis  Center  (ECAC). 

If  the  SEI  were  to  be  modelled  after  ECAC,  administrative 
responsibility  would  be  delegated  to  one  of  the  Services.  The 
Director  could  be  an  0-6,  rotated  among  the  Services. 
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6.0  IMPLEMENTATION  PLAN 

Irrespective  of  the  alternatives  chosen,  as  discussed  in 
Sections  4  and  5,  the  SEI  should  have  a  minumum  life  of  10  years, 
This  will  allow  for  the  effective  integration  and  delivery  of  any 
technology  flowing  from  the  five  year  STARS  program.  The  SEI  may 
be  continued  beyond  10  years  if  a  need  is  perceived. 

The  SEI  will  be  funded  under  a  multi-year  contract  with 
options.  The  initial  contract  will  be  competed,  university 
and  non-profit  corporations  will  be  encouraged  to  participate. 
Successfull  performance  by  the  winner  will  assure  a  5  or  more 
year  period,  of  performance  before  recompetition.  Poor  performance 
would  result  in  cancellation  of  the  options  years  and  a 
recompetition  after  3  years. 

The  overall  operation  of  the  SEI  will  be  evaluated 
continually  by  DoD  for  effectiveness.  The  evaluation  will  be 
supported  by  performance  measures.  The  performance  measures 
will  be  used  to  compare  results  to  objectives  and  the  stategic 
operating  plan. 

It  will  take  several  years  from  its  inception  for  the 
SEI  to  reach  full  operating  capacity.  A  start-up  strategy  for 
this  phase  is  presented  in  section  6.1.  The  personnel  resources 
and  facility  requirements  are  presented  in  6.2.  An  estimate  of 
the  costs  for  the  first  five  years  of  operation  is  presented  in 
section  6.3. 
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6.1  START-UP  STRATEGY 


It  will  take  several  years  to  reach  the  steady  state 
operations  of  the  SEX  described  in  Section  3  of  this  plan.  A 
start-up  plan  describes  how  the  SEX  will  reach  steady  state 
operations.  The  start-up  plan  does  not  address  the  activities 
required  to  award  a  contract  for  SEI  operations.  These 
activities  are  summarised  in  Figure  8  which  assumes  an  October 
1983  contract  initiation.  It  is  recognized  that  this  is  an 
optimistic  milestone ,  but  until  a  more  realistic  date  can  be 
decided  upon,  this  date  will  be  used  since  it  provides  for  fiscal 
year  alignment  of  the  start-up  plan  phases  with  the  fiscal  year 
budget  given  in  Section  5.3.  The  remainder  of  this  section 
describes  the  phases  the  SEI  will  pass  through  following  contract 
award  to  the  hosting  agent.  This  plan  is  not  affected  significantly 
by  the  DoD  management  alternative  chosen.  It  addresses  the  host 
agent  activities,  only. 

The  SEI  life  cycle  operation  can  be  viewed  in  four 
phasest  initiation,  pilot  operation,  expansion,  and  steady 
state.  The  first  three  of  these  phases  are  the  subject  of 
the  start-up  plan.  Figure  9  shows  the  major  activities  asso¬ 
ciated  with  the  three  start-up  phases.  Each  of  the  three 
phases  will  last  one  year.  After  three  years,  steady  state 
operations  will  be  attained. 

6.1.1  Initiation  Phase 

The  initiation  phase  will  establish  the  basic  elements 
required  for  SEI  operations.  These  elements  are: 
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ACTIVITY 


F 


Business  p.lan  approach 
RFP  Preparation 
RFP  Approval 
RFP  Issue 

Proposal  preparation 
Proposal  Submission 
Proposal  Evaluation 
Contractor  Selection 
Negot iatlon 
Contract  Start 


CONTRACT 


Initiation 
FY8  4 


Pilot 
Operation 
FY8  5 


Furnish  &  Equip 
SET  Facility 

Develop  Preliminary 
Support  Environment 

Establish  CM  Process 

RD  Baseline 
Research  Survey 

Personnel  Hiring  Program 

PR/Newsletter  Process 


Establish  Pilot  Projects 

Formalize  PD  Operations 

Baseline  and  Preliminary 
Release  of  Support 
Environment 

Establish  Measurements 
Program 

Evaluate  and  Redirect  SEI 


Fill  Out  Organization 

Expand  Projects  to  10 

Release  1  of  Support 
Environment 


Figure?:  Start-up  Plan  Phases 
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Facilities  -  the  SEI  offices,  computer  center,  and 
computer  laboratories  will  be  furnished  and  equipped 
to  a  level  sufficient  for  pilot  operations. 

Preliminary  support  environment  -  Using  an  advanced 
release  version  of  MAPSE,  an  operational  environment 
will  be  brought  up  and  stabilized  at  the  SEI  computer 
center.  Proper  channels  will  be  established  for  the 
continued  coordination  of  MAPSE  releases  to  the  SEI. 

Product  Definition  and  Configuration  Management 
Process  -  The  management  process  and  supporting 
tools  whereby  the  support  environment  enhancements 
will  be  approved,  integrated,  and  released  will  be 
defined . 

Baseline  Research  Survey  -  A  baseline  survey  of 
research  in  software  engineering  will  be  produced 
by  RD  to  serve  as  the  basis  for  continuing  RD 
activity  and  to  select  pilot  projects. 

Personnel  Hiring  Program  -  the  Administrative 
group  responsible  for  personnel  will  be  established. 
They  will  create  the  mechanisms  and  contacts 
necessary  to  hire  the  SEI  permanent  staff  and  to 
keep  a  continuing  stream  of  visiting  scientists 
pumping  through  the  SEI. 


f.  Public  Relations  and  SSI  Newsletter  -  The  Admini¬ 
strative  group  responsible  for  public  relations 
will  be  established  to  set  up  lines  of  communication 
with  the  software  community. 

6.1.2  Pilot  Operations  Phase 

The  pilot  operations  phase  will  establish  the  operation 
of  the  SEI  in  a  skeletal  form  to  evaluate  the  operational 
concept  and  make  appropriate  changes  prior  to  expansion  to 
full  operation.  The  primary  activities  initiated  in  this 
phase  are: 

a.  Pilot  Projects  -  Two  to  four  pilot  projects  will 
be  initiated  by  the  Outreach  Division.  The  pilot 
projects  will  be  selected  from  the  survey  produced 
by  RD  during  the  initiation  phase,  and  from  a 
list  of  internal  technology  projects  aimed  at 
research  into  integration  and  transition  tech¬ 
niques. 

b.  Product  Division  Operations  -  formally  begin  PD 
operations  by  setting  into  action  the  product 
definition  and  configuration  management  process. 
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c.  Baseline  support  environment  Trial  Release  -  the 
preliminary  support  environment  will  be  upgraded 
with  the  most  current  MAPSE  pre-release.  The 
release  process  will  be  exercised  (without 
actually  releasing  a  product)  to  iron  out  any 
problems. 

d.  Measurements  Program  -  The  SEI  effectiveness 
measures  will  be  implemented  by  the  Operations 
Division  and  will  be  applied  to  the  pilot  operation. 

e.  Evaluation  -  the  pilot  operation  will  be  evaluated. 
The  main  purpose  of  the  evaluation  will  be  to 
determine  if  the  concept  of  operation  is  feasible 
based  on  the  results  of  the  pilot  operation.  The 
operations  will  be  reshaped  where  appropriate 
before  expanding  to  full  operations. 

6.1.3  Expansion  Phase 

The  expansion  phase  will  focus  on  the  expansion  of  the  SEI 
to  full  manning,  approximately  10  active  projects,  and 
full  Products  Division  operations.  The  primary  activities 
of  this  phase  are: 

a.  Fill  Out  Organization  -  the  SEI  manning  will  be 
increased  to  the  steady  state  manning. 


b.  Projects  -  The  Outreach  projects  will  be  increased 
to  as  many  as  tan. 

c.  support  environment  -  the  first  release  of  the  F 
sponsored  support  environment  will  be  delivered  to 
the  Services. 

6.2  RESOURCE  REQUIREMENTS 

The  primary  resources  required  to  operate  the  SEI  are 
people,  buildings,  and  computer  equipment.  The  SEI  will  be 
manned  with  a  permanent  staff  and  visiting  scientists. 

Support  contractors  will  be  used  as  needed.  Figures  10,  11, 
and  12  show  the  manning  growth  of  the  SEI  over  the  three 
start-up  phases  culminating  in  a  steady  state  manning  of 
116  (81  permanent  and  35  visiting)  at  the  end  of  the  expansion 
phase . 

The  SEI  will  be  located  in  a  University  of  a  non-profit 
corporation  setting.  Office  and  laboratory  space  will  be 
provided  along  with  the  necessary  equipment  to  support  the 
evaluation,  integration,  and  delivery  of  software  engineering 
technology. 
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ORGANIZATION 
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Figure  10:  Initiation  Phase  Manning 
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Figure  11s  Pilot  Operations  Phase  Manning 
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Figure  12:  Expansion  Phase  Manning 


The  office  apace  for  the  Institution  must  be  sufficient 
to  support  a  minimum  of  116  professionals  and  supporting 
clerical  staff.  At  least  14,000  square  feet  of  office  space 
will  be  required.  Space  for  a  central  computer  complex, 
terminals,  and  five  computer  laboratories  also  will  be 
required.  Another  2,000  square  feet  will  service  this  need. 

The  office  and  laboratory  space  should  be  colocated  for  ease 
of  access  and  communications  among  the  Institute  staff. 

The  offices  will  be  equipped  initially  with  desks,  chairs, 
file  cabinets,  etc.  to  support  the  professional  activities. 

Office  automation  equipment  including  word  processors,  copiers, 
and  facsimile  devices  will  be  provided.  At  least  70  terminals 
and  workstations  will  be  required  to  support  the  day-to-day 
activities  for  the  professional  staff.  A  local  area  network 
may  be  used  to  provide  interconnection. 

A  central  computer  complex  consisting  of  a  configuration 
suitable  for  the  support  of  a  large  support  environment  operation 
will  be  provided.  This  complex  will  be  capable  of  supporting 
the  70  terminals  in  a  time-sharing  environment,  connection, 
and  dial-up  teleprocessing.  A  v  iriety  of  mini  and  microcomputers 
may  be  used  in  the  computer  laboratories. 

The  central  computer  resources  will  be  tied  to  the  outside 
world  via  the  ARPANET  and  dial-up  lines.  High  speed 
communications  lines  also  may  be  desirable  for  direct 
transimission  of  support  environment  releases  to  the  Services. 


6.3  FINANCIAL  PLAN 

The  financial  plan  for  the  first  five  years  of  SEI  opera¬ 
tion  is  shown  in  Figure  13.  The  figures  do  not  include  the 
cost  of  the  acquisition  activities  summarized  in  Section  5.1, 
Figure  8.  The  budgets  for  all  five  years  are  expressed  in  1984 
dollars.  All  facilities  and  capital  equipment  are  budgeted  on 
a  lease  basis. 

The  salaries  are  estimated  using  the  manning  levels  shown 
in  Figures  10,  11,  and  12.  The  average  annual  salaries  for 
each  labor  category  were  assumed  to  be  as  follows: 

Average 
Base 

Permanent  professional  $  60,000 

Visiting  professional  50,000 

Technical/clerical  20,000 

These  salaries  are  increased  by  15%  to  account  for  fringe 
benefits  (insurance,  FICA,  disability)  before  computing  the  salary 
budgets.  Further,  it  is  assumed  that  the  salaries  of  50%  of  the 
visiting  professionals  are  paid  by  their  sponsoring  organizations. 

The  overhead  includes  utilities,  telephone,  supplies,  travel, 
conferences,  accounting  services,  etc.  A  flat  rate  of  20%  of 
salaries  is  assumed.  Since  overhead  expense  will  be  incurred  on 
all  staff,  the  salaries  of  those  visiting  professionals  sponsored 
by  their  employers  are  included  (i.e.  visiting  professional  salari 
shown  in  Figure  13  are  doubled  before  computing  overhead) . 


Figure  33  :  SEI  5-Year  Financial  Plan 


The  facilities  costs  are  computed  assuming  an  annual  cost 
of  $15  per  square  foot.  The  space  requirement  for  each  of  the 
five  years  is  assumed  to  be: 

FY84  :  5,000  square  feet 

FY85  s  11,000  square  feet 
FY86-88:  16,000  square  feet 

The  capital  equipment  items  are  budgeted  as  leased  equipment. 
The  aentral  computer  complex  includes  computers ),  disks,  tapes, 
printers,  communications  equipment,  and  other  supporting  equipment. 
Five  hundred  thousand  dollars  per  year  is  budgeted  for  the  fully 
configured  complex.  Equipment  for  the  computer  labs  - 
microcomputers,  graphics  terminals,  etc.  -  is  estimated  at  a 
value  of  $500,000  or  a  lease  cost  of  $200,000  per  year.  The 
average  monthly  cost  of  office  furnishings  per  person  is  $100. 

In  addition,  $300  per  month  per  person  is  assumed  for  terminals 
(computer  timeshare,  word  processors,  etc.). 

Subcontractor  support  is  assumed  for  specialty  skills  and 
load  levelling  of  the  SEI  workload.  One  hundred  thousand  dollars 
per  man  year  is  assumed.  The  contract  manning  level  assumed  is 
shown  below. 

FY84  :  4 

FY8  5  :  10 

FY86  :  16 

FY87-88:  20 
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APPENDIX 


SOFTWARE  ENGINEERING  INSTITUTE 
ISSUES  AND  ALTERNATIVES  RAISED  AT  THE 
STARS  WORKSHOP,  7-9  Feb  83 
TECHNOLOGY  INSERTION  PANEL 


The  following  13  areas  received  considerable  attention  by  Panel  members  and 
were  addressed  in  open  session  comments  at  the  Workshop.  A  brief  description 
of  the  issue  and  alternatives  is  given  and  a  rationale  provided  for  the  Panel 
consensus. 

1.  Should  the  SEI  focus  its  software  engineering  efforts  on  the  embedded 
computer  applications  area  or  to  a  broader  scope  of  software  development  areas? 

Consensus:  Embedded  computer  systems. 

Rationale :  DOD  embedded  computer  systems  (ECS)  are  critical  to  our  National 
defense  posture.  They  stress  the  extremes  of  such  system  characteristics. 
Unlike  the  ADP  application  environment,  where  industries  focus  their  R&D 
efforts,  little  industry  effort  is  put  on  defense  unique  ECS  applications. 
The  DOD  must  focus  its  attention  on  this  area.  Industry  R&D  will  satisfy 
most  Defense  ADP  needs. 

2.  Should  the  SEI  provide  products  and  services  and  foucs  its  attention  to  the 
Defense  community  or  to  all  areas  and  users  of  ECS? 

Consensus:  The  Defense  community. 

Rationale :  This  question  is  related  to  the  first.  Because  COD  resources 
are  limited,  the  SEI  should  focus  on  defense  needs.  Non-sensitive  spin-off 
technology  will  have  commercial  application  and  will  be  made  available. 

The  scope  of  the  SEI  mission  and  focus  could  be  broadened,  perhaps, 
with  a  larger  basis  of  support  from  outside  the  DOD.  This  is  discussed 
in  #8  below. 

3.  Should  the  SEI's  primary  mission  be  limited  to  engineering  and  integration 
of  software  development  technology  or  should  it  support  and  accomplish  software 
research  as  well? 

Consensus:  The  consensus  favored  including  research  in  the  SEI  mission. 

Rationale:  A  significant  portion  of  the  SEI  staff  is  to  be  mads  up  of 
visiting  researchers  who  will  bring  software  research  products  to  the 
Institute  for  engineering  and  integration  into  the  Institute's  software 
development  environment.  A  strong  research  program  will  encourage  this 
infusion  of  quality  people. 

In  addition,  the  Institute  should  do  research  on  software  development 
environment  msasurenents  and  technology  transition. 


4.  Should  the  Institute  be  responsible  for  maintaining  the  DOD  "standard" 
software  development  environment  for  all  services  to  use? 

Consensus :  No. 

Rationales  Current  Service  policies  separately  address  the  standardization 
o£  computer  resources  including  development  systems.  As  the  Ada  language 
and  programming  support  envirorments  are  developed,  there  will  be  a 
convergence  towards  commonality. 

The  SEI  will  develop  and  maintain  an  advanced  environment  compatible 
with  the  Ada  programing  environments  developed  by  the  Services.  This 
will  assure  the  efficient  transition  of  new  tools  fran  the  Insititute  to 
the  Services  and  their  contractors. 

3.  Should  the  Institute  provide  software  engineering  education  and  training? 

A  possible  extension  of  the  mission  might  be  an  extensive  academic  program,  to 
the  possible  extent  of  a  degree  granting  institution. 

Consensus:  Education  and  training  to  support  tool  and  practice  transition 
should  be  accomplished.  Additional  education  in  general  software  development 
involving  the  SEI  environment  should  be  carried  on.  The  training  should 
be  presided  to  key  Service  and  contractor  personnel  who  would  then  provide 
the  education  to  larger  groups  of  environment  users. 

Rationale :  Broadening  the  scope  of  education  would  require  greater  SEI 
resources  than  available.  The  Services  have  their  undergraduate  and 
graduate  programs  as  well  as  other  training  programs  which  should  provide 
for  general  needs. 

6.  Should  the  SEI  provide  facilities  and  offer  canputer  processing  (including 
software  tools)  resources  and  services  for  fee? 

Consensus:  It  seemed  appropriate  that,  at  the  beginning,  only  limited 
services-for-fee  should  be  provided.  Such  services  involving  the  use  of 
new  tools  could  be  provided  as  a  way  of  introducing  these  tools  as  wall  as 
evaluating  their  effectiveness  in  real  applications. 

Rationale:  A  larger  operation  to  provide  canplete  environment  and  remote 
canputer  service  capability  for  the  DOD  community  seemed  very  ambitious. 

It  could  be  an  SEI  growth  possibility  if  its  effectiveness  and  feasibility 
is  demonstrated  by  initial,  smaller  scale  experiments. 

7.  Are  the  scope,  size,  and  budget,  as  proposed,  compatible? 

Consensus:  The  size  and  scope  are  compatible.  The  budget  as  proposed  was 
not  adequate. 

Rationale:  The  budgeted  amounts  for  personnel  were  too  small.  (These 
amounts  have  been  increased  in  the  current  plan.) 


8.  Should  the  management  and  the  support  for  trie  SEI  be  DOD  baaed  or  broader 
based?  Should  other  Government  agencies,  i.e.,  NASA,  FAA,  etc,,  be  included? 
Should  organizations  outside  Government  be  involved  in  support  and  management 
of  the  SEI? 

Consensus:  Although  strong  suggestions  for  a  "National"  SEI  were  heard, 
the  Panel  recommended  limiting  management  for  the  DOD.  Support  grants  can 
be  accepted  from  outside  but  not  direction. 

Rationale;  The  focus  should  be  maintained  to  support  the  Defense  can- 
muni  ty  embedded  computer  software  engineering  area.  Thus,  management 
should  be  limited  to  the  DOD. 

9.  How  should  the  SEI  be  managed  within  the  DOD  —  by  OSD,  by  the  Services 
jointly,  or  by  a  single  Service? 

Consensus:  The  SEI  is  a  part  of.  the  STARS  Program  and  probably  will  remain 
part  of  this  program  as  long  as  it  exists.  The  STARS  Program  is  currently 
planned  as  a  joint-Service  managed  program,  the  management  to  be  canposed  of 
Service  representatives. 

Rationale:  The  above  was  not  throughly  worked  cut.  Strong  Service  views 
exist  that  the  SEI,  and  possibly  the  STARS  program  as  wall,  should  be 
Service  managed. 

10.  What  vehicle  or  host  institution  should  be  used  to  organize  and  establish 
the  SEI  —  a  university  or  university  consortium,  a  not-for-profit  company,  a 
for-profit  corporation,  or  a  service  or  Agency? 

Consensus:  The  university,  university  consortium,  or  not-for-profit 
corporation  were  favored. 

Rationale:  The  DOD  is  personnel  resource  limited.  Establishing  the  SEI 
within  the  DOD  would  cause  a  personnel  resource  redistribution  which  would 
adversely  effect  other  functions.  DOD  salary  structure  would  limit  the 
effectiveness  in  obtaining  quality  personnel. 

The  motivation  of  for-profit  industry  appears  incanpatible  with  the 
free  interchange  of  ideas  necessary  for  the  SEI. 

Sane  expressed  tha  belief  that  researchers  would  be  better  attracted 
to  university  environment. 

11.  Orientation  of  the  Institute  —  user  needs  or  technology  push? 

Consensus :  User  needs 

Rationale:  The  requirements  of  software  developers  in  industry  and  in 
Service  centers  nust  be  the  driver  for  the  SEI  activities. 


12.  Type  of  personnel  required  for  the  SEI  irission  —  world-class  researchers 
or  other  types? 

Consensus :  A  variety  of  personnel  will  be  required  to  staff  a  successful 
SEI,  both  engineering  and  research. 

Rationale;  A  specific  type  of  engineering  resource  is  required  to  transition 
engineer,  and  integrate  software  engineering  too 1j  and  develop  advanced 
environments.  A  thorough  understanding  of  the  application  —  software 
engineering  of  real  systems  —  is  needed.  "World-class"  researchers 
probably  are  not  the  best  resource;  however,  these  people  must  still  be 
attracted  to  the  Institute  to  bring  in  new  ideas. 

13.  Name.  Alternative  names  for  the  Institite  were  suggested  and  discussed. 

One  in  particular  —  "Software  Engineering  Technical  Center"  —  was  favored. 

Consensus:  There  was  no  mandate  to  change  the  none. 

Rationale ;  It  is  appropriately  left  until  the  mission  and  made  of  operation 
are  determined. 


